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RESPONSE TO EXAMINER'S ANSWER 



There are a few new issues or cited art interpretations that were newly made in the 
Examiner's Answer, for which Appellants feel a need to respond to in order to establish a clear 
record of the differences between the claimed features in the present Apphcation and the teachings 
of the cited references. 

Lazaridis Reference and Backup Command/Application Identifier (with respect to Claim 6) 

On page 3 of the Examiner's Answer, the Examiner provides a new reasoning for how the 
cited Lazaridis reference teaches pushing of a command to a wireless device to backup data - 
stating that this is taught at 'col. 7, lines 31-34 and col. 4, lines 45-46, column 1, lines 30-43; 
instead of mobile device requesting synchronization, host uses push paradigm that continuously 
transmits user selected data items upon detection of trigger event' (emphasis added by Appellants). 
Appellants urge that such continuous transmission of user selected data items: (1) does not teach or 
suggest any pushing of a command to the wireless device to back up data, and (2) further evidences 
that there would have been no motivation to modify the teachings of the cited references in 
accordance with the inventive features expressly recited in Claim 1 . 

First, Lazaridis' pushing/transmitting of user selected data items does not teach or 
otherwise suggest any pushing of a command to a wireless device to backup data. Instead, data 
items such as e-mail messages, calendar events, etc. are pushed to the wireless device (Lazaridis 
col. 3, lines 14-20). The fact that Lazaridis may teach sending a confirmation to a host that the data 
has been received does not somehow redefine the data that is sent to the wireless device into being 
some type of command to a wireless device to backup data (see, e.g. page 11, Argument B of the 
Examiner's Answer). 

Second, and as just shown, Lazaridis is directed to continuously pushing of data items, and 
not commands, to a wireless device (Lazaridis col. 1, lines 35-39; col. 3, lines 14-20). As expressly 
admitted by the Examiner in the rejection of Claim 7 (which is further discussed below), none of 
the cited references teach or otherwise contemplate a wireless device that retrieves and executes an 
apphcation to transmit data, that was requested to be backed up, to a server. Thus, there would be 
no reason for either of the teachings of the cited references to include in a textual based service 
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load a uniform resource identifier for an application that the wireless device may retrieve and 
execute on the wireless device in order to transmit to a server data that was requested to be backed 
up, as neither reference describes a wireless device that performs such functionality and therefore 
there would be no need or other reason to provide such identifier in a textual based service load as 
it would serve no purpose other than to adversely impact system performance by needlessly 
transmitting commands that serve no useful purpose. Thus, it is urged that the only possible 
motivation for modifying the teachings of the cited references in accordance with the missing 
features of Claim 6 must be coming from Appellants' own disclosure and claims, which is 
impermissible hindsight analysis. 

Muir Reference and Application Retrieval (with respect to Claim 7) 

On page 4 of the Examiner's Answer, the Examiner provides a new interpretation of the 
teachings of the cited Muir reference at col. 3, lines 1-42; Abstract; and Figure 1, and now states 
that Muir teaches 'The hyperlink (uniform resource identifier) associated with the configuration file 
is therefore used to retrieve the apphcation'. This is clearly an erroneous interpretation of the 
teachings of Muir, as will now be described. 

Claim 7 in combination with its independent Claim 6 recites features of: 

"pushing, over the wireless network to the wireless device, a request to backup 
data, wherein the step of pushing the request comprises sending a textual based 
service load to a proxy server, wherein the service load provides a uniform 
resource identifier for an application that the wireless device may retrieve to 
transmit the data to the server" 

As can be seen, as a part of the step of pushing to the wireless device a command to backup data, 
a textual based service load is sent to a proxy server - and this service load provides a uniform 
resource identifier for an application that the wireless device may retrieve in order to transmit the 
data (being backed up) to the server. Muir does not teach any such application (identified by a 
uniform resource locator) that a client may retrieve to transmit data to the server. Muir's 
application, as requested by a client, is always executed by the server and not by a client or 
wireless device. This can be seen by numerous passages in Muir. For example, as stated by 
Muir at col. 1, lines 45-50: 
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Although hypermedium has been used to transfer information to a user in the 
manner just discussed, it is desirable to be able to use a hypermedium display to 
interactively execute applications such as database programs located on 
another computer, an application execution server , on the network. The present 
invention relates to a method and apparatus to accomplish this task. 

This remote application execution can also be seen at col. 1, line 54 - col. 2, line 13, where it 
states: 

"The invention relates to a system of making a hypermedium page interactive to 
thereby permit an application to be executed on one node and the results displayed 
and data entered on another node. In one embodiment the system includes a chent 
node, a network server node and an application execution server node 
interconnected by a communication link. A hyperlink on the hypermedium page is 
displayed on the client node and a hyperlink configuration file (corresponding to the 
hyperlink on the chent node) is located on the network server node. In one 
embodiment, a client agent is located on the chent node and a server agent is 
located on the apphcation execution server node. A communication link is created 
by the client agent between the chent agent on the chent node and the server agent 
on the apphcation execution server node in response to data in the hyperlink 
configuration file. The system also includes an application on the application 
execution server node which executed on the application execution server node 
in response to the communications link between the client agent and the server 
agent. The application running on the application execution node then 
communicates with the client agent through the server agent. The chent agent on the 
chent node is responsible for receiving data input from the user and transferring the 
data to the application on the application execution node and receiving data from 
the application on the application execution node and displaying data output to 
the user on the chent node." 

This remote application execution can also be seen at col. 2, line 63 - 67, where it states: 

"A user on a client node wishing to run the application program 36 which is 
located on the application execution server 24 on the web 32 does so through a 
graphical user interface 40, which is herein referred to without any loss of 
generality as a hypermedium, located on the client node 10." 

This remote application execution can also be seen at col. 3, lines 12 - 42, where it states: 

"The network browser 64 obtains the first page or web page 44 from a network 
server node 18 and displays the web page 44 on the hypermedium 40 for the user to 
view on the graphical display device 42. When the user selects an apphcation 
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program 36 to execute (by selecting a graphical 48 or textual 56 hyperlink using the 
mouse 46 or keyboard 50) the network browser 64 obtains a network configuration 
file 68 corresponding to the selected apphcation 36 from a predetermined network 
server 1 8 and starts a client agent 72 which will communicate with the selected 
application 36. This will be discussed in more detail below. 

The chent agent 72 reads the configuration file 68 and estabhshes a 
communications link to a server agent 80 on the application execution server 24 
specified by the configuration file 68. In one embodiment, the configuration file 68 
includes the name of the apphcation and the node location of the apphcation 36 
corresponding to the hyperlink 48, 56. The configuration file may also contain 
optional information such as authentication or authorized user information. Server 
agent 80 performs the operations necessary (such as authentication) to permit the 
chent agent 72 access to the apphcation 36, and once access is permitted, starts the 
application 36 requested by the user. Once the apphcation 36 is executing on 
the application execution server, the application 36 communicates through the 
server agent 80 directly with the chent agent 72 without intervention by the network 
browser 64. The chent agent 72 is then responsible for receiving data from the user 
through the mouse 46 and keyboard 50 and transmitting it to the application 
program 36 on the apphcation execution server 24." 



This remote application execution can also be seen at element 36 of Muir Figure 1, where the 
application is shown to exist solely within Apphcation Execution Server 24. 

The entire premise of Muir is to provide an ability for a chent to remotely execute an 
apphcation that executes remotely on an apphcation execution server. The URL that the user 
selects does not identify an application that the wireless device may retrieve to transmit data 
(being backed up) to a server, as now newly alleged by the Examiner on page 4 of the Examiner's 
Answer. Instead, Muir teaches a configuration file that contains data including the name of the 
apphcation to be executed on a remote server/host. Again, this configuration file is not used to 
identify an application that a wireless device may retrieve transmit data to a server, as now newly 
alleged by the Examiner. 

It is further shown that this cited Muir reference is deficient in what it is alleged to teach, as 
Muir does not contemplate any type of wireless device, and therefore it does not teach - nor would 
there have been a reason or other motivation to modify such teachings - to include a service load 
that provides an application identifier, as expressly recited in Claim 7. The Examiner states that a 
web page provides the alleged identifier, and a web page is clearly different from a service load (as 
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that term is commonly known to those of ordinary skill in the art). 

In addition, because of the fundamental architectural differences between the teachings of 
Muir and the features of Claim 7 (for example, where the application is actually executed by the 
wireless device to transmit data to a server, as claimed), a person of ordinary skill in the art would 
not have been motivated to essentially eviscerate the entire premise and purpose that is provided by 
the Muir system in modifying such teachings in accordance with the features of Claim 7 - further 
evidencing that Claim 7 is not obvious in view of the cited references, and has therefore been 
erroneously rejected. 

In a second paragraph regarding the Claim 7 discussion of Muir in the Examiner's 
Answer, the Examiner expressly acknowledges that Muir teaches that the application is executed 
on the server and not received by the wireless device. However, the Examiner goes on to state 
that it would have been obvious to receive that application at the wireless device (as evidenced 
by Lazaridis et al who teaches the redirector program is executed on the wireless device), in 
order to use the application on the device to backup data. Appellants urge numerous errors in 
such obviousness assertion, as will now be described. 

A person of ordinary skill in the art would not have been motivated to modify the 
location of where the Muir application is executed, as the entire premise of Muir is to provide an 
ability for a chent to initiate execution of an application that executes remotely on an apphcation 
execution server. Such a modification would essentially eviscerate the entire premise and purpose 
that is provided by the Muir system of remote application execution that executes on an apphcation 
execution server - evidencing no motivation to make such a modification. 

Nor do the teachings of Lazaridis somehow trump the Muir teachings to provide such 
motivation. Again, due to the fundamental Muir architecture, a person of ordinary skill in the art 
would not have been motivated to strip the Muir teachings of their fundamental and primary 
purpose and therefore substitute teachings of a totally different architected system such as the 
one taught by Lazaridis. 

Even if one where to eviscerate the Muir teachings, there would still be no teaching or 
suggestion of the claimed feature of "wherein the service load provides a uniform resource 
identifier for an application that the wireless device may retrieve to transmit the data to the 
server". Because Lazaridis does not teach a redirector program that is solely executed on a 
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wireless device, but instead teaches a redirector program that operates on both of the host system 
and the wireless device (Lazaridis col. 4, lines 47-48), there would be no reason to send a URL 
identifier of an application to be executed on a client due to this built-in tandem execution of the 
redirector program by both the host system and the wireless device - further evidencing non- 
obviousness as there would have been no motivation to modify such teachings in accordance 
with the missing claimed feature pushing a command to a wireless device to backup data that 
includes as application identifier for client retrieval of an application to transmit data to a server. 

Lazaridis Reference and Application Identifier (with respect to Claim 10) 

On page 7 of the Examiner's Answer, the Examiner states (at Section 16): 

"As per claim 10, Lazaridis et al teach a method on a proxy server for facilitating 
data backup, the method comprising: 

receiving a request from a backup server for a wireless device chent to 
backup data to the backup server (column 7, lines 31-34, column 4, lines 45-56 
and column 4, lines 46-56), wherein the request is a textual based service load 
providing the wireless client with a uniform resource identifier for an application 
which will identify, locate and transmit the requested data to the backup server;" 

Curiously, this is diametrically opposite to the Examiner's position taken with respect to the 
teachings of Lazaridis and Claim 10 in the Final Office Action dated August 11, 2006. There, 
the Examiner stated in rejecting this same Claim 10 (on page 15, Section 42): 

"As per claim 10, Lazaridis et al fail to teach providing the client with a uniform 
resource identifier for an application which will identify, locate and transmit the 
requested data to the backup server" (emphasis added by Appellants) 

Appellants agree with this previous Examiner assessment of the teachings of the cited Lazaridis, 
as such reference does not in fact teach providing a client with a uniform resource identifier for 
an application which will identify, locate and transmit the requested data to the backup server. 
In rejecting the claimed 'receiving a request from a backup server' aspect of Claim 10, for which 
the claimed application identifier feature is recited within, the Examiner states in the present 
Examiner's Answer that the such claimed 'receiving' step is taught by Lazaridis at column 7, 
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lines 31-34, column 4, lines 45-56 and column 4, lines 46-56. Appellants urge that Lazaridis 
description at the cited column 7 passage describes network events being transmitted to a host 
system, and such passage does not describe any providing of anything to a client , such as an 
application identifier, as claimed. The Lazaridis description at the cited column 4 passage 
describes pushing certain user-defined events /rom the mobile device to the host system , and such 
passage does not describe any providing of anything to a client , such as an application identifier, 
as claimed. The Lazaridis description at the cited column 4 passage is a duplicate citation of the 
same column 4, lines 46-56 previously cited as teaching such claimed application identifier 
feature. Thus, contrary to the Examiner's assertion in the Examiner's Answer - and yet 
consistent with the Examiner's previous position in finally rejecting Claim 10 (in the Final 
Office Action dated August 1 1 , 2006) - the cited Lazaridis reference does not teach the claimed 
feature of "receiving a request in a first protocol from a backup server for a wireless client to 
backup data to the backup server, wherein the request is a textual based service load providing 
the client with a uniform resource identifier for an application which will identify, locate, and 
transmit the requested data to the backup server". Thus, a proper prima facie showing of 
obviousness has not been established with respect to Claim 10, and accordingly such claim has 
been erroneously rejected. 
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CONCLUSION 



It is therefore respectfully submitted that all pending claims have been erroneously 
rejected, as described hereinabove and in Appellants' Appeal Brief, and Appellants thus request 
that the Board reverse the final rejection of all such claims. 
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